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Abstract 

Complementary  Processing ,  (CP),  is  a  scheduling 
methodology  to  increase  software  execution  speed \  Ex¬ 
periments  were  performed  to  test  CP  with  command  and 
control  software,  specifically ,  to  measure  the  effect  of  CP 
on  the  speed  of  processing  Navy  track-message  data .  A 
37.5-fold  increase  was  observed  in  this  preliminary  test . 
Recommendations  for  future  tests  are  discussed. 

1.  Introduction 

The  Navy  is  investigating  Complementary  Processing, 
(CP),  a  scheduling  methodology  for  increasing  software 
execution  speed  [1],  to  evaluate  its  utility  in  improving  the 
performance  of  command  and  control  systems.  The  Global 
Command  and  Control  System  -  Maritime  (GCCS-M), 
includes  software  modules  for  tracking  the  ship  positions. 
An  experiment  measured  the  speed  of  execution  of  the 
track-processing  software  both  with  and  without  CP. 

2.  Experimental  methods 

The  experiment  simulated  the  transmission  of  Link  16 
track  messages  from  the  Advanced  Combat  Direction  Sys¬ 
tem  (ACDS)  into  the  GCCS-M  software  using  a  network 
with  TCP/IP.  The  Link  16  transmitter  was  simulated  by  an 
IBM-compatible  personal  computer  (PC)  that  was  used  to 
construct  a  data  stream  consisting  of  messages  with  infor¬ 
mation  derived  from  actual  GCCS-M  track  data.  The  PC 
simulator  produced  a  stream  of  track  data  in  the  same  for¬ 
mat  as  an  operational  Link  16  data-format  message  firm 
ACDS.  The  PC  fed  this  Linkl6  data  stream  into  the 
JMCIS  Hewlett  Packard  (HP)  Model  Cl  10  computer  run¬ 
ning  the  HP-UX  OS  version  10.2. 

These  data  were  received  in  the  GCCS-M  HP  machine 
and  processed  in  the  same  manner  as  in  an  operational  sce¬ 
nario.  The  GCCS-M  software  parsed  and  processed  the 
incoming  track  data  and  stored  the  processed  tracks  in 
shared  memory.  Tracks  from  the  PC's  Link  16  simulator 
received  time  stamps  -  one  upon  receipt  at  the  HP  input 
port  and  another  upon  storage  in  the  HP's  shared  memory 
to  enable  the  calculation  of  the  processing  time  for  each 
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track  transaction.  This  procedure  was  repeated  using  the 
GCCS-M  software  in  its  original  state,  until  the  processing 
time  durations  were  recorded  for  of  all  baseline  tracks. 

The  choice  of  shared  memory  for  data  storage,  as  op¬ 
posed  to  a  flat-file  database,  was  a  design  decision  based  on 
the  performance  of  GCCS-M  independent  of  CP  and  is  not 
associated  with  CP's  requirement  for  shared  memoiy.  The 
use  of  shared  memoiy  to  store  the  processed  track  data  ob¬ 
viated  the  necessity  to  perform  multiple  disk  I/Os  during 
data  collection  and  provided  a  more  efficient  test  design. 

When  the  baseline  test  was  complete,  CP  software  was 
installed  on  the  HP  computer,  but  not  on  the  PC.  The 
GCCS-M  software  remained  the  same  as  it  was  in  the  base¬ 
line  test.  The  entire  test  was  repeated  using  the  same 
Link  16  data  stream  that  was  used  in  the  baseline  test.  The 
measured  processing  durations  with  CP  were  compared  to 
those  without  CP.  The  mean,  mode,  median  and  standard 
deviation  for  the  time  differences,  both  with  and  without 
CP,  were  calculated.  A  Performance  Improvement  Factor 
(PIF)  was  calculated  to  summarize  the  effect  of  CP's  contri¬ 
bution  to  the  processing  speed. 

3.  Data  analysis  and  results 

The  CP  software  affixed  the  time  stamp  upon  data  input 
and  to  each  output  record  that  GCCS-M  wrote  to  shared 
memory  at  the  conclusion  of  the  GCCS-M  software  proc¬ 
essing.  A  module  that  consisted  of  instructions  to  read  the 
system  clock  and  a  write  to  it  memory  was  necessary  in 
lieu  of  modifications  to  the  GCCS-M  software  that  would 
have  added  an  internal  time-stamp  generator.  This  addi¬ 
tional  software  was  not  expected  to  contribute  a  long  delay 
to  the  total  processing,  and  therefore  its  execution  time  was 
ignored  during  these  preliminary  tests. 

This  method  of  time  measurement  allows  the  GCCS-M 
software  to  be  tested  in  an  unmodified  and  undisturbed 
state.  B(J)  is  the  baseline  time  trial  with  CP  absent  and 
C(J)  is  the  test  time  trial  with  CP  present. 

Data  were  collected  to  determine  two  time  intervals  for 
each  track,  dt(B(J))  and  dt(C(J).  The  baseline  time  interval 
for  a  track  processed  without  CP  is  given  by: 


Data  were  collected  to  determine  two  time  intervals  fir 
each  track,  dt(B(J))  and  dt(C(J).  The  baseline  time  interval 
for  a  track  processed  without  CP  is  given  by: 

dt(B(J))  =  OUTPUT  t(B(J))  -  INPUT  t(B(J))  (1) 

Similarly,  the  test  time  interval  for  a  track  with  CP  is: 

dt(C(J))  =  OUTPUT  t(C(J)>  -  INPUT  t(C(J))  (2) 

where  dt  signifies  the  time  difference  and  t(B(J))  is  the  no¬ 
tation  for  the  time  stamp  of  the  data,  e:g.  INPUT  t(B(J))  is 
the  time  the  track  was  recorded  in  the  test  data  generator 
and  OUTPUT  t(B(J))  is  the  time  that  the  track  was  re¬ 
corded  as  it  was  stored  in  shared  memory  with  JMCIS  and 
without  CP  software. 

The  CP  software  affixes  a  time  stamp,  called  INPUT 
t(C(J)),  to  each  track  as  it  is  released  from  the  data-stream 
generator  the  PC.  CP  also  affixes  a  time  stamp,  OUTPUT 
t(C(J),  to  each  track  when  it  is  stored  in  shared  memory. 

The  standard  deviation,  S,  of  the  sample  was  calculated 
according  to  the  following  formula: 

S  =  {(X(xi  -<x>)2)/(n-l)}  m  (3) 

where  Xj  is  the  value  of  the  i1*1  processing  duration,  <x>  is 
the  mean  processing  duration,  and  n  is  the  sample  size  of 
95  for  both  baseline  and  CP  test  trials. 

Preliminary  tests  indicate  a  significant  increase  in  the 
speed  of  processing  95  trials  of  periodic  GCCS-M  track 
data  with  the  addition  of  CP.  Whereas  100  trials  woe 
completed,  5  were  discarded  due  to  questionable  results, 
such  as  zero  processing  time  recorded,  duplicate  records,  or 
an  anomalous  first  time  derivative  that  occurred  for  one 
baseline  track.  The  statistics  are  summarized  in  Table  1. 

Table  1.  Summary  of  GCCS-M  track-processing  dura¬ 
tions  in  psec  for  data  processed  without  and  with  CP. 


dt(B(J))  dt(C(J)) 

Statistic - (Baseline  trials)  ( CP  test  trials) 

Mean  661529.  17624.2 

Mode  663243.  107492. 

Median  661522.  5646. 

S  709.265  25560.7 


The  PIF,  the  ratio  of  the  mean  processing  durations 
without  CP  and  with  CP,  is  as  follows: 

PIF  =  <dt(B(J))>  /  <dt(C(J))>  (4) 

where  the  brackets  indicate  the  mean  values  from  Table  1 . 
The  numerical  value  for  the  PIF  was  37.5,  which  was  ob¬ 
tained  on  the  HP  UX  system,  which  does  not  support 
threads.  CP  is  expected  to  increase  processing  speeds  about 
30%  more  than  this  in  a  thread-enabled  environment. 

4.  Discussion  and  recommendations 
An  examination  of  the  raw  baseline  data,  INPUT  B(J), 
and  OUTPUT  B(J),  reveals  dramatic  evidence  of  the  ineffi¬ 
ciency  of  interrupt  processing.  The  data  for  the  first  track 
were  received  at  the  HP's  input  port  at  t  =  0  and  were  not 
frilly  processed  and  stored  in  shared  memory  until  t  = 
660315  psec.  During  this  time  interval  for  processing  the 
first  track,  the  data  for  all  of  the  other  tracks  were  received 
at  the  HP  input  port.  Therefore,  while  the  CPU  was  proc¬ 
essing  computations  associated  with  the  first  (and  subse¬ 
quent)  track(s),  it  was  interrupted  multiple  times.  The  last 


track  data  set  was  received  at  the  input  port  prior  to  the 
time  when  GCCS-M  completed  processing  the  data  for  the 
first  track  and  prior  to  storing  the  processed  data  of  the  first 
track  in  shared  memory.  The  last  track  was  not  fully  proc¬ 
essed  until  all  processing  of  prior  tracks  had  completed, 
causing  the  last  track  to  have  the  longest  processing  time. 

.  The  processing  durations,  dt(B(J))i,  exhibit  a  systematic 
increase  with  increasing  value  of  i.  Thus,  the  mean  value 
<dt(B(J))>  is  a  function  of  the  number  of  tracks,  n.  This 
result  is  expected  because  the  processing  time  increases 
with  the  number  of  interrupts,  degrading  the  processing 
efficiency  roughly  in  a  linear  manner 

dt(B(J))i  =  mi  +  b  (5) 

where  b  is  a  constant,  i  is  the  number  of  the  track,  and  m 
is  the  slope  of  the  linear  function.  In  this  case,  m  was  21 
psec,  +  or  -  2  psec. 

Equation  (5)  is  valid  in  several  segments  over  the  range 
for  which  available  shared  memory  can  accommodate  addi¬ 
tional  processed  data  sets  (e.g.  more  tracks).  Due  to  the 
limited  shared  memory,  more  than  95  baseline  trials  could 
not  be  processed  successfully.  Equation  5  is  not  valid  in 
several  trials  in  which  the  GCCS-M  software  appeared  to 
take  much  longer  to  process  the  data  than  in  most  cases. 
Violations  of  (5)  occurred  to  a  lesser  extent  due  to  the  pe¬ 
riodicity  fluctuations  in  data  inputs  generated  by  the  PC. 

The  distributions  of  processing  durations  for  both  the 
baseline  data  and  the  CP  test  trials  were  observed  to  be 
highly  asymmetric  and  skewed.  For  example,  in  the  CP 
trials,  the  72  values  fell  below  the  mean  whereas  23  values 
were  above  the  mean.  This  asymmetry  also  is  expressed  in 
the  differences  between  the  mean,  the  mode  and  the  median 
for  each  set  of  durations,  both  dt(B(J))  and  dt(C(J)). 

Whereas  the  result  for  baseline  trials  were  consistent 
with  theory ,  the  values  of  the  processing  durations  for  CP 
trials  exhibited  much  more  variance  than  was  expected 
based  on  the  theoretical  predictability  of  processing  infor¬ 
mation  frames  and  time  periods.  This  is  expressed  in  Ta¬ 
ble  1  by  the  large  value  of  S  equal  to  25560.7  psec.,  which 
is  almost  1.5  times  larger  than  the  mean  processing  dura¬ 
tion  for  CP.  S  for  baseline  processing  durations  was  con¬ 
siderably  smaller.  This  discrepancy  between  theory  and 
experimental  observation  requires  further  investigation. 

The  mean  processing  duration  of  the  CP  and  the  PIF  are 
encouraging,  but  these  results  are  preliminary.  Additional 
tests  are  needed  to  explain  the  following  observations: 

•  large  standard  deviation  for  CP  processing  duration, 

•  highly  unusual  distribution  of  CP  processing  durations 
with  wide  variance  in  mean,  mode,  and  median  values, 

•  discontinuities  in  linear  function  of  baseline  track  proc¬ 
essing  durations  vs.  track  number,  and 

•  shared-memory  limitations  on  the  number  of  test  trials. 

For  further  directions  regarding  future  research,  see  [1]. 
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